REMARKS 



In an office action mailed October 8, 2002 (paper no. 5), claims 1-3, 5-8, and 10-13 were 
rejected under 35 U.S.C. 102(b) as being anticipated by U.S. patent 5,832,451 granted to Flake et 
al. ("Flake"). Claims 15-19 were rejected under 35 U.S.C. 102(a) as being anticipated by "Hotel 
Reservations Network Taps Pegasus Systems to Expand Online Hotel Reservations Capabilities 
Agreement; Adds 22,000 Hotels to HRN's Consumer Website," PR Newswire, New York, Sept. 
30, 1998 ("HRN"). Claims 4, 9, and 14 were rejected under 35 U.S.C. 103(a) as being 
unpatentable over Flake in view of HRN. Claim 20 was rejected under 35 U.S.C. 103(a) as being 
unpatentable over HRN in view of Flake. These rejections are respectfully traversed. 

Rejections Under 35 U.S.C. 102 

Claims 1-3, 5-8, and 10-13 were rejected under 35 U.S.C. 102(b) as being anticipated by 
Flake. In particular, it is alleged that Flake discloses a "master reservation system receiving the 
reservation data and storing the reservation data in a database, the master reservation system 
receiving the update data and updating the database with the update data." Claims 15-19 were 
rejected under 35 U.S.C. 102(a) as being anticipated by HRN. In particular, it is alleged that 
HRN discloses "storing reservation data reflecting the current status of two or more properties 
from two or more reservation data systems in a database." These rejections are respectfully 
traversed. 



Flake fails to provide a prima facie basis for the rejection of claims 1-3, 5-8, and 10-13, 
because it fails to disclose each element of the claimed inventions. In regards to claim 1, Flake 
fails to disclose "a reservation data system interface receiving reservation data and update data 
from two or more reservation systems; and a master reservation system coupled to the reservation 
data system, the master reservation system receiving the reservation data and storing the 
reservation data in a database, the master reservation system receiving the update data and 
updating the database with the update data." Instead, Flake discloses a travel agency 12 that 
interfaces with a plurality of computer reservation systems 14. A business entity profile 18 or 
individual profile 20 is used to interface with each of these computer reservations systems 14, but 
reservation data and update data from the computer reservation systems is not stored at travel 
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agency 12 other than that associated with reservations that have already been made. "System 10 
maintains the business and individual entity profile information, along with all available 
customer reservation information, in the relational database." Flake, col. 4, lines 4-6. System 10 
does not maintain reservation inventory information. "Preferably, the inventory information 
provided by computer reservation systems 14 is ultimately received for processing by system 10. 
Generally, system 10 preferably functions to centralize the travel service information received 
from each of computer reservation systems 14." Flake, col. 3, lines 32-37. Thus, in order to 
make a reservation using the system of Flake, it is necessary to interface with each of the 
different computer reservation systems 14. 

In contrast, claim 1 allows a user to make a reservation without interfacing with two or 
more different computer reservation systems. A reservation data system interface receives 
reservation data and update data from two or more reservation systems. The reservation data can 
include but is not limited to room availability data, and the update data and include but is not 
limited to changes to the room availability data that result from reservations made at the hotel or 
by other systems. Likewise, claim 8 provides storing reservation data from two or more 
reservation data systems in a database; receiving status update data from one or more of the 
reservation data systems; and updating the database with the status update data. Thus, the system 
of claim 1 and the method of claim 8 eliminate the need to query each computer reservation 
system and the associated delay for such queries, while maintaining the reliability of the data. As 
to claim l| a master reservation system coupled to the reservation data system receives the 
reservation data and update data and stores the reservation data and update data in a database, 
such that a user interface system coupled to the master reservation system can receive reservation 
request data and providing updated reservation data in response to the reservation request data. 
Flake utterly fails to disclose this, and requires users to interface with each computer reservation 
system 14 to receive updated reservation data in response to the reservation request data. Thus, 
Flake not only fails to disclose this feature, it fails to provide any motivation to be combined 
with other art to provide this feature. 
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/ Claim 2 includes a monitoring system storing sequence number data associated with the 
update data. The cited section of Flake has nothing to do with sequence number data associated 
with update data - "at block 278, the system receives travel arrangement information from the 
[passenger name record] stored in the relational database, and compares the information with a 
predetermined set of quality criteria." Flake, col. 11, lines 49-52. What are these "quality" 
criteria? "[T]he QA software routine can search all available computer reservation systems for 
lower rates than those that were booked by the agent. If the QA software identifies such an 
"error," the software prompts system 10 to generate a "flag" which indicates that some corrective 
action should be taken." Flake, col. 7, lines 47-54. Not only does this cited section of Flake 
clearly demonstrate that any access to reservation data by the system of Flake is made by 
querying the external computer reservation systems and not an internal database that is updated, 
it also demonstrates that there is absolutely no need for sequence number data associated with the 
update data for the reservation data by Flake, as there is no such update data to be associated 
with sequence data. Thus, Flake not only fails to disclose this feature, it fails to provide any 
motivation to be combined with other art to provide this feature. 

Claim 3 includes a master reservation interface system coupled to the reservation data 
system interface and one of the reservation data systems that receives the update data from the 
reservation data system and transmits the update data to the reservation data system interface. 
Flake fails to disclose any such master reservation interface system coupled to the reservation 
data system interface and one of the reservation data systems, and instead discloses that 
"although each computer reservation system formats its travel service information and command 
structures differently, system 10 functions to integrate the different information and commands 
into one format for use by all travel agents." Flake, col. 3, lines 36-41. Thus, the system of 
Flake converts computer reservation system formats at system 10, instead of distributing that 
conversion functionality to each of the reservation data systems. There is simply no need or 
functionality that could be provided in Flake for a master reservation interface system coupled to 
the reservation data system interface and one of the reservation data systems that receives the 
update data from the reservation data system and transmits the update data to reservation data 
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system interface. Thus, Flake not only fails to disclose this feature, it fails to provide any 
motivation to be combined with other art to provide this feature. 

Claim 5 includes the master reservation system further comprising a property system that 
receives property modification data and updates the database with the property modification data. 
This feature is also entirely missing from Flake, which has no need to receive property 
modification data, which can include but is not limited to data that identifies additional rooms, 
reduced numbers of rooms, or new classes of rooms. Instead, Flake obtains this information 
from each computer reservation system 14, which store all inventory information, including any 
increases or decreases of rooms at a property or changes to classes of rooms. Flake, col. 3, lines 
32-37. Thus, Flake not only fails to disclose this feature, it fails to provide any motivation to be 
combined with other art to provide this feature. 

Claim 6 includes the master reservation system further comprising a rate plan system that 
receives rate plan modification data and updates the database with the rate plan modification 
data. Again, Flake has no need for such a system, as all inventory information is maintained by 
the computer reservation systems 14. Flake, col. 3, lines 32-37. Any quality assurance that is 
performed to determine whether a lower rate is available must be accomplished by querying each 
of the computer reservation systems 14. Flake, col. 1, lines 47-54. Thus, Flake not only fails to 
disclose this feature, it fails to provide any motivation to be combined with other art to provide 
this feature. 

Claim 7 includes the master reservation system further comprising a distribution channel 
system that receives distribution channel modification data and updates the database with the 
distribution channel modification data. Flake does not even mention distribution channels, 
which are further described in the specification at page 18, lines 10-15. The cited section of 
Flake only reveals a single distribution channel - the travel agent. Any distribution channel 
functions must be performed by each of the computer reservation systems 14 of Flake when 
needed to assist with the making of a reservation, Flake, col. 7, lines 47-54. Thus, Flake not 
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only fails to disclose this feature, it fails to provide any motivation to be combined with other art 
to provide this feature. 

Claim 10 includes the method of claim 8 wherein storing reservation data from two or 
more reservation data systems in a database comprises storing property data. There is no need 
to store property data associated with reservation data in Flake, as such data is obtained from 
each of the computer reservation systems 14 when needed to assist with the making of a 
reservation. Flake, col. 7, lines 47-54. Thus, Flake not only fails to disclose this feature, it fails 
to provide any motivation to be combined with other art to provide this feature. 

Claim 1 1 includes the method of claim 8 wherein storing reservation data from two or 
more reservation data systems in a database comprises storing rate plan data. There is no need 
to store rate plan data associated with reservation data in Flake, as such data is obtained from 
each of the computer reservation systems 14 when needed to assist with the making of a 
reservation. Flake, col. 7, lines 47-54. Thus, Flake not only fails to disclose this feature, it fails 
to provide any motivation to be combined with other art to provide this feature. 

Claim 12 includes the method of claim 8 wherein receiving status update data from one or 
more of the reservation data systems comprises receiving room availability update data. There 
is no need to receive room availability update data in Flake, as such data is managed by each of 
the computer reservation systems 14. Flake, col. 1, lines 47-54. Thus, Flake not only fails to 
disclose this feature, it fails to provide any motivation to be combined with other art to provide 
this feature. 

Claim 13 includes the method of claim 8 wherein receiving status update data from one or 
more of the reservation data systems comprises receiving room price update data. There is no 
need to receive room price update data in Flake, as such data is managed by each of the computer 
reservation systems 14. Flake, col. 1, lines 47-54. Thus, Flake not only fails to disclose this 
feature, it fails to provide any motivation to be combined with other art to provide this feature. 



013742.0018 DALLAS 615644 vl 



10 



HRN fails to provide a prima facie basis for the rejection of claim 15, as it fails to 

disclose "storing reservation data reflecting the current status of two or more properties from two 

or more reservation data systems in a database; receiving a request for reservation data for one or 

more of the properties; and providing reservation data reflecting the current status of the 

property." The cited sections of HRN do not disclose that reservation data reflecting the current 

status of two or more properties from two or more reservation data systems are stored in the 

database. "The advanced technology enables users of third-party Web sites to access Pegasus' 

database of approximately 22,000 hotels in 165 countries and provides them with the ability to 

shop and query room availability, view photos, make a reservation online and receive a 

confirmation in seconds." As stated in the Background of the Invention at paragraph 4: 

[Reservation systems for multiple facilities use static databases that reflect a 
small number of rates and availability data that is updated infrequently or not 
at all. A frequent problem encountered by such users is that the first reservation 
system will indicate availability of reservations or a particular rate, but upon 
contacting the local reservation data system, the user will find that the rate does 
not exist, or that rooms are not available. Thus, users of such reservation 
systems for multiple facilities must not only contact a reservation data system 
for each separate lodging facility of interest, but also frequently encounter 
facilities that do not have the rates of interest or do not have room availability. 
Thus, a user who is attempting to find a number of comparable properties to do 
a price comparison or provide options to a traveler must often directly contact a 
large number of properties to obtain on several choices or price points. 

HRN merely discloses such a static database, which was operated by the Assignee of the pending 
application. The current status of two or more properties from two or more reservation data 
systems in a database is not received by such prior art systems, and as such, reservation data 
reflecting the current status of the property can not be provided. As such, HRN fails to provide a 
prima facie basis for the rejection of claim 15. 

Claim 16 includes the method of claim 15 wherein storing reservation data reflecting the 
current status of two or more properties from two or more reservation data systems in a database 
further comprises updating the database with status update data. The system disclosed in HRN 
does not receive status update data reflecting the current status of two or more properties, but 
rather uses a static database that reflects a small number of rates and availability data that is 



013742.0018 DALLAS 615644 vl 



11 



updated infrequently or not at all. Therefore, HRN fails to provide a prima facie basis for the 
rejection of claim 16. 

Claim 17 includes the method of claim 16 wherein updating the database with status 
update data further comprises storing a transaction sequence number. The system disclosed in 
HRN does not receive status update data reflecting the current status of two or more properties, 
but rather uses a static database that reflect a small number of rates and availability data that is 
updated infrequently or not at all, and as such, would have no need to store a transaction 
sequence number, such as for the reasons disclosed in the specification at paragraph 26 or for 
other suitable reasons. Therefore, HRN not only fails to provide a prima facie basis for the 
rejection of claim 17, it fails to provide any motivation to be combined with other art to provide 
this feature. 

Claim 18 includes the method of claim 15 wherein receiving the request for reservation 
data for one or more of the properties comprises receiving a request for distressed inventory. 
Distressed inventory by its nature is volatile, as it includes discounted rooms or other items that 
are attractive because of their lower price. The system disclosed in HRN is particularly 
unattractive for distressed property, as it is merely the combination of the system used by Hotel 
Reservation Network with that used by Pegasus, such that a user can receive information from 
either source, but where the sources are not combined. "Pegasus Systems' online reservation 
service provides third-party Web sites with direct access to the same hotel reservation and 
confirmation capabilities provided by Pegasus Systems' consumer retail site. . . . advanced 
technology enables users of third-party Web sites the ability to shop and query room availability, 
view photos, make a reservation online and receive a confirmation in seconds." HRN page 1 at 4. 
Thus, each property must deal independently with Hotel Reservations Network and Pegasus 
Solutions, and must segregate which properties to provide through Hotel Reservations Network 
and which properties to provide through Pegasus Solutions. The invention of claim 18 eliminates 
the need for the bifurcated and redundant process of HRN. As such, HRN teaches away from a 
combination with other art to yield the invention of claim 18. 
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Claim 19 includes the method of claim 15 wherein receiving the request for reservation 
data for one of the properties comprises receiving a request for rate plan data. The system 
disclosed in HRN does not receive rate plan data reflecting the current status of two or more 
properties, but rather uses a static database that reflects a small number of rates and availability 
data that is updated infrequently or not at all. Therefore, HRN fails to provide a prima facie basis 
for the rejection of claim 19. 

As described above, withdrawal of the rejection of claims 1-3, 5-8, and 10-13 under 35 
U.S.C. 102(b) as being anticipated by Flake and of claims 15 through 19 under 35 U.S.C. 102(a) 
as being unpatentable over HRN is respectfully requested. 

Rejections Under 35 U.S.C. 103 

Claims 4, 9, and 14 were rejected under 35 U.S.C. 103(a) as being unpatentable over 
Flake in view of HRN, and claim 20 was rejected under 35 U.S.C. 103(a) as being unpatentable 
over HRN in view of Flake, In particular, it is acknowledged that Flake does not disclose a chain 
system receiving chain modification data and receiving distressed inventory data, and that HRN 
does not disclose receiving a request for negotiated rate data. These rejections are respectfully 
traversed. 

Flake in view of HRN fails to provide a prima facie basis for the rejection of claim 4, as it 
fails to teach or suggest each element of the claimed invention. Claim 4 includes the system of 
claim 1 wherein the master reservation system further comprises a chain system receiving chain 
modification data and updating the database with the chain modification data. As previously 
discussed, Flake is drawn to a system where computer reservation systems are accessed by the 
travel agency 12, and where a database of reservation data is not stored. Likewise, as previously 
discussed, HRN discloses a static database, where the current status of two or more properties 
from two or more reservation data systems is not received and stored in a centralized database. 
As such, Flake teaches away from the combination with HRN - how do you combine a system 
with a static, infrequently-updated centralized database with a system that queries each individual 
computer reservation system 14 of Flake? How would conflicts between data obtained by each 
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process be resolved? If the chain data in the static, infrequently-updated database conflicted with 
corresponding chain data from the computer reservation system 14 of Flake, which would take 
precedence? Flake and HRN are simply unable to be combined, and even if they were combined, 
they fail to teach or suggest the invention of claim 4. 

Likewise, the combination of Flake and HRN is improper with regards to claims 9, 14, 
and 20. Claim 9 includes the method of claim 8 wherein storing reservation data from two or 
more reservation data systems in a database comprises storing hotel chain data. There is no need 
to store hotel chain data associated with reservation data in Flake, as such data is obtained from 
each of the computer reservation systems i4 when needed to assist with the making of a 
reservation. Flake, col. 1, lines 47-54. Claim 14 includes the method of claim 8 wherein 
receiving status update data from one or more of the reservation data systems comprises: 
receiving distressed inventory data. There is no need to receive distressed inventory data for two 
or more properties in Flake, as such data is managed by each of the computer reservation systems 
14. Flake, col. 7, lines 47-54. Claim 20 includes the method of claim 15 wherein receiving the 
request for reservation data for one of the properties comprises receiving a request for negotiated 
rate data. There is no need to receive negotiated rate data for two or more properties in Flake, as 
such data is managed by each of the computer reservation systems 14. Flake, col. 7, lines 47-54. 
Thus, Flake not only fails to disclose these features, it fails to provide any motivation to be 
combined with other art to provide this feature. Likewise, a combination of Flake with HRN 
creates the same data conflict problems with respect to claims 9, 14, and 20 as previously 
discussed with respect to claim 4. As such, withdrawal of the rejection of claims 4, 9, and 14 
under 35 U.S.C. 103(a) as being unpatentable over Flake in view of HRN, and of claim 20 under 
35 U.S.C. 103(a) as being unpatentable over HRN in view of Flake is respectfully requested. 

New claims 21 through 25 are presented herewith for examination, and are believed to 
also be distinguishable from the prior art. No new matter has been added. 
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CONCLUSION 



In view of the foregoing remarks and for various other reasons readily apparent, 
Applicants submit that all of the claims now present are allowable, and withdrawal of the 
rejection and a Notice of Allowance are courteously solicited. 

If any impediment to the allowance of the claims remains after consideration of this 
amendment, and such impediment could be alleviated during a telephone interview, the 
Examiner is invited to telephone the undersigned at (214) 969-4669 so that such issues may be 
resolved as expeditiously as possible. 

A check for an additional fee of $90.00 for five (5) additional dependent claims is 
submitted herewith. No additional fee is believed to be due. If any applicable fee or refund has 
been overlooked, the Commissioner is hereby authorized to charge any fee or credit any refund to 
the deposit account of Akin, Gump, Strauss, Hauer & Feld, L.L.P., No. 01-0657. 




G{iri§k(pherJ. Rourk 
Reg. No. 39,348 
Attorney for Applicants 



Akin, Gump, Strauss, Hauer & Feld, l.l.p. 

P.O. Box 688 

Dallas, TX 75313-0688 

(214) 969-4669 
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VERSION WITH MARKINGS SHOWING CHANGES MADE TO THE CLAIMS 

21. (NEW) The system of claim 1 wherein the reservation data includes room 
availability data for each of the available rooms at each property managed by each of the two or 
more reservation systems, and where the update data includes rented room data at one of the 
properties that reflects rooms that were previously indicated as being available at that property 

5 and which have since become unavailable. 

22. (NEW) The system of claim 1 further comprising: 

a master reservation interface system coupled to the reservation data system interface and 
one of the reservation data systems, the master reservation interface system receiving the update 
data from the reservation data system and transmitting the update data to reservation data system 
5 interface; 

a status update system providing status update data that includes room reservation data 
and rate change data to the master reservation interface system when the status update data becomes 
effective for the corresponding reservation system; and 

wherein the master reservation interface system transmits the status update to the master 
1 0 reservation system upon receiving the status update data from the status update system. 

23. (NEW) The method of claim 15 wherein storing reservation data reflecting the 
current status of two or more properties from two or more reservation data systems in a database 
comprises: 

receiving status update data at a local property reservation system when a room at a 
5 property has been reserved; 

transmitting the status update data to the database; and 

updating a central database to decrease the number of available rooms for the property. 

24. (NEW) The method of claim 15 wherein storing reservation data reflecting the 
current status of two or more properties from two or more reservation data systems in a database 
comprises: 

16 
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receiving status update data at a local property reservation system when a rate plan at a 
5 property has been changed; 

transmitting the status update data to the database; and 

updating a central database to change the rate plan for each of the rooms for the property. 

25. (NEW) The method of claim 15 wherein storing reservation data reflecting the 
. current status of two or more properties from two or more reservation data systems in a database 
comprises: 

receiving status update data at a hotel chain reservation system when distribution channel 
5 data for a hotel chain has been changed; 

transmitting the status update data to the database; and 

updating a central database to change the distribution channel data for each of two or 
more properties in the hotel chain. 
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